Table of Contents

 

Abstract 1

What is this Protocol for? Audience. 2

Protocol Description. 2

Layer 2 AX.25 Integration. 2

Routing Layer 3

Routing Methods. 3

Transport Layer 4

Client 4

Version Information. 4

Disclaimer and License Statement 5

 

 

Abstract

 

This document contains the description of a protocol to enable the Layer 2 AX.25 digipeaters to operate over TCP/IP connections.

 

It’s intended to expand the geographical scope and coverage of a given radio network relying on the routing mechanisms inherent to the TCP/IP suite of protocols.

 

At the same time, it’s a protocol designed to allow the usage of existing infrastructure components (digipeaters, FlexNet or NET/ROM nodes) making the details of the protocol both compatible with the AX.25 protocol specificacion and transparent to their operation.

 

The initial implementation of the protocol is been made using the AGW Packet Engine by George Rossopoulos (SV2AGW) as the enabling platform; other platforms could adopt the basic set and implement it achieving interoperability as it seems it fit.

 

 

 

 

 

What is this Protocol for? Audience.

 

The main audience of this protocol are application programmers willing to support a common interchange protocol that enables interoperability based on the digipeating of AX.25 frames over TCP/IP connections.

 

Protocol Description

 

The protocol allows the transparent integration of AX.25 L2 Digipeaters, as defined on the AX.25 Protocol Version 2.0, across TCP/IP connections.

 

In such a way that frames could be transparently relayed across any two points where a TCP/IP connectivity could be established in real time.

 

The protocol has three main parts:

 

·        Layer 2 AX.25 Integration.

·        Routing Layer.

·        Transport. Layer.

 

Layer 2 AX.25 Integration

 

Frames are transported over radio links following the AX.25 protocol conventions in a way that infrastructure resources not enabled for this protocol could handle the frames transaparently.

 

A special infrastructure device, an AX.25 L2 Worm Digipeater over TCP/IP or TCPeater, is introduced by this protocol.

 

This device will listen to frames been exchanged over a radio link till the following conditions are met:

 

• A frame indicates the CALLSIGN-SSID of the device as a part of the path (VIA) information and it has the “Has been digied” bit in “0” indicating that the frame has not been digipeated by the device yet.
• All other CALLSIGN-SSID prior to it (if any) has the “Has been digied” bit in “1” signaling that the frame has been properly digipeated by the upstream chain.
• There is at least one other CALLSIGN-SSID more at the digipeater path and it has the “Has been digied” bit in “0”.

 

If such conditions are met the following actions are performed:

 

• The “Has been digied” bit associated with the CALLSIGN-SSID of the device is set to “1” (marking the frame has been digipeated).
• The Routing layer of the protocol is activated, upon return the frame will be flagged as “To be Repeated” or “To be Discarded”.
• If flagged as “To be Repeated” the frame is repeated over the radio link it should have been if this protocol were not operating.
• If flagged as “To be Discarded” the frame is discarded, no state or memory will be held at the device of it.

 

Please note that to disable the support for this protocol on a given device the logic is exactly the same except that no Routing Layer is involved and all frames are marked as “To be Repeated” automatically.

 

This arrangement will make the mechanism used by this protocol completely transparent to non-enabled digipeaters.

 

Routing Layer

 

The routing layer is the responsible to define if the frame provided by the lower L2 integration level of the device is

 

• Forward Routing (Client -> Server)
• Suitable to be transported over a TCP/IP connection.
• Which TCP/IP route to use for it.
• Needed to be either discarded or repeated by the L2 integration level.
• Reverse Routing (Server->Client)
• Handle the incoming frames and define which port will be used to transmit it.

 

Forward Routing

 

Those are the actions that took place when a frame is routed from the client to the server of the connection.

 

In order to do that the following actions will be performed:

 

• The next digipeater with “Has been digied” in “0” at the digipeater path will be fetch.
• If there is none the frame will be marked as “To be Repeated” to the L2 integration level and all routing activities finalized.
• If there is at least one more digipeater indicated the frame the CALLSIGN-SSID will be fetch on a routing table dept by the device.
• If a route is found the IP Adress and TCP port will be recovered.
• The frame will be passed to the Transport Layer for handling indicating the IP Address and TCP Port to which it has to be contacted.
• The frame will be marked to the L2 integration level as “To be Discarded”.
• If a route is not found the frame will be marked to the L2 integration level as “To be Repeated”.

 

Reverse Routing

 

Reverse routing deals when a frame is received from a remote node (thru the transport layer listener) and the definition of which radio port will be used to air it.

 

Basically, each listener has to be associated with a particular radio port, so each frame received from it will be transmitted over that particular one, each router is reponsible to define to which radio port a given frame has to be digipeated thru.

 

Verifications will be made that the radio port is a valid one before attempting to transmit it.

 

No state is preserved after a frame had been route.

 

Routing Methods

 

The mechanism used to build and maintain routes is left outside the scope of this protocol specificacion and up to the particular implementation of the device, the following options do exist:

 

• Static Routing.

 

Routes to be used are statically configured, each CALLSIGN-SSID suitable to be used as the destination of a route will have th IP Address and TCP Port of it’s listener socket indicated.

 

• Dynamic Routing.

 

Routes are created or updated as activity occurs based on actual connections from the outside; basically whenever a connection is received on the listener the IP Address of the origin is remembered and updated.

 

• A combination of Static and Dynamic Routing.

 

Both the Static and Dynamic routing schemes have advantages and disadvantages, so it’s likely that devices implementing this protocol will use a mix of both.

 

 

Route Layer Information

The router layer is responsible to generate a routing frame and to send it to the other end at the beginning of each connection, that frame could be optionally used by the other end to update dynamically routes:

 

The format of the frame will be

 

o       Port: Don’t care, fill with 0x00.

o       From, CALLSIGN-SSID of the digipeater initiating the connection.

o       To, CALLSIGN-SSID of the digipeater receiving the routing.

o       DataKind, ‘Z’.

o       Pid, ‘0xCF’.

o       DataLength: 2

o       Info, the TCP Port of the local listener (LSB/MSB).

 

 

Transport Layer

 

A transport layer will be implemented thru the combination of one TCP Socket Listener and one or more TCP Socket Clients in order to route frames between any two endpoints of the TCP/IP connection.

 

Client

 

Frames routed by the upstream Routing Layer will be handled by the Client side of the transport layer according with the following specifications:

 

·        A TCP Socket will be opened, if not existing previously, frames will be buffered while the connection is established.

·        If the connection succeed all buffered frames will be sent to the other end.

·        If the connection fails all buffered frames will be discarded.

·        Frames will be sent encapsulated into a AGWPE ‘D” TCP/IP frame format using the following conventions:

o       Port: Don’t care, fill with 0x00.

o       From, CALLSIGN-SSID of the digipeater making the routing.

o       To, CALLSIGN-SSID of the digipeater receiving the routing.

o       DataKind, ‘D’.

o       Pid, ‘0xCF’.

o       DataLength the length of the AX.25 frame to be transported.

o       Info, the actual AX.25 frame to be transported.

 

No other control mechanism will be used since the TCP protocol will care the frames are received at the other end in the proper sequence, with the full content and any delivery mechanism problem will be handled at the TCP level.

 

The other end (listener) defines which radio port will be used to transmit the frame over radio, no control on the client side is provided by this protocol.

 

Listener (Server)

 

The listener will accept the connection of remotes over TCP/IP, each server will operate over a single radio channel in order to create a full, non-ambiguous, bidirectional channel across both ends. More than one listener per device could be operating simultaneously and will be either differentiated by the CALLSIGN-SSID it uses, the TCP port it serves or both.

 

Data flowing thru the connection will be handled in the following way:

 

• A valid AGWPE ‘D’ frame will be received, fragmentation will be handled by the receiver.
• Upon a successful reception of a frame the info part of it will be extracted containing the actual AX.25 frame to be digipeated.
• The following verification will be performed if any of the verification fails the frame will be discarded by the receiver end, no further notification to the other end will be performed.
• The last digipeater in the path with “Has been sent” bit in “1” must be the CALLSIGN-SSID stated in the FROM part of the AGWPE frame received.
• The first digipeater in the path with “Has been sent” bit in “0” must be the CALLSIGN-SSID stated in the TO part of the received AGWPE frame received.
• The TO part of the received AGWPE frame has to be recognized by the receiving device as it’s own.
• If the previous verification succeeded the frame will be marked with the “Has Been Sent” bit as “1” on the digipeater corresponding to the server operating the listener and will be transmitted over the designated radio port associated with the listener.
• Upon transmition no further action will be performed nor state will be preserved for the frame.

 

 

Version Information

 

 

• Version 1.0 (Preliminary)

Initial protocol description.

 

 

Disclaimer and License Statement

 

This protocol has been devised to promote experimentation on amateur radio digital modes, as such it is considered to be placed in the public domain.

Publicly available information has been used to understand the requirements, specially the AGWPE TCPIP Interface (AGWSockInterface.DOC by G.Rossopoulos SV2AGW) and the “AX.25 Amateur Packet Radio Link Layer Protocol” (AX25.DOC), all code used to implement this program remains under the ownership of the respective authors.

 

AX.25:   LU7DID@LU7DID.#ADR.BA.ARG.SOAM

Inet:    colla@pec.pccp.com.ar

 

 

Appendix – Frame Formats

 

The frame formats to be used are as follows:

 

Field	Length	“D” Frame	“Z” Frame
AGWPE Port	1 Bytes	0x00	0x00
Reserved	3 Bytes	0x00	0x00
DataKind	1 Byte	D (ASCII 0x44)	Z (ASCII 0x5A)
Reserved	1 Byte	0x00	0x00
PID	1 Byte	0xCF	0xCF
Reserved	1 Byte	0x00	0x00
CallFrom	10 Bytes	Digipeater FROM	Digipeater FROM
CallTo	10 Bytes	Digipeater TO	Digipeater TO
DataLen	4 Bytes	Length of Frame	2
User (Reserved)	4 Bytes	0x00 0x00 0x00 0x00	0x00 0x00 0x00 0x00
Info	As indicated in DataLen	Raw AX.25 Frame	TCP Port (LSB/MSB)

 

In the case of the “D” frame the format of the info will be:

 

Field	Length	Description
RadioPort	1 byte	Not Used 0x00
Address	112/360 bits	AX.25 coded Origin, Destination and digipeaters.
Control	1 byte	AX.25 Control Field
PID	1 byte	AX.25 PID (Only I and UI frames)
Info	N bytes	AX.25 Information Area

 

Please see the AX.25 Version 2.0 Protocol documentation for the description of the fields. Please note that no FCS nor Start/Stop Flag fields are used.